Industrial controllers and their associated control programming are central to the operation of modern industrial automation systems. These controllers interact with field devices on the plant floor to carry out controlled processes relating to such objectives as manufacture of a product, material handling, batch processing, waste water treatment, and other such processes. The controllers typically exchange data with the field devices using native hardwired I/O or via a plant network such as Ethernet/IP, Data Highway Plus, ControlNet, Devicenet, or the like. The controller receives any combination of digital or analog signals from the field devices indicating a current state of the devices and their associated processes (e.g., temperature, position, part presence or absence, fluid level, etc.), and executes a control program that performs automated decision-making for the controlled processes based on the received signals. The controller then outputs appropriate digital and/or analog control signaling to the field devices in accordance with the decisions made by the control program. These outputs can include device actuation signals, temperature or position control signals, operational commands to a machining or material handling robot, and the like. The control program can comprise any conceivable type of code used to process input signals read into the controller and to control output signals generated by the controller, including but not limited to ladder logic, sequential function charts, function block diagrams, structured text, or other such platforms.
During development of a given control program, a plant simulation is often used to validate the program prior to deployment. This simulation emulates various aspects of the physical system to be regulated by the control program (e.g., actuators, sensors, etc.) and interfaces with the control program under test to exchange I/O data in order to simulate real-time control. The plant simulation generates digital and analog values representing sensor or telemetry data, which are provided to the control program as simulated physical inputs. The control program processes these simulated inputs and generates digital and/or analog output data in accordance with the program algorithms, and provides this output data to the plant simulation. The plant simulation then updates the simulated control input values based on the control outputs provided by the control program in a manner that simulates operation of the real-world system. In this way, the control program can be tested and debugged without putting field equipment and machinery at risk.
There are a number of inefficiencies inherent to conventional industrial simulation techniques that are detrimental to data fidelity, update rates, and simulation accuracy. For example, since there are no physical field devices wired to the controller's I/O modules during simulation, simulated I/O data must be exchanged via a direct connection to the controller's I/O data table. That is, output data generated by the control program is read directly from the controller's data table by the simulation rather than being converted to an electrical signal and transmitted by the controller's physical output points. Likewise, simulated I/O data generated by the simulation must be written directly to the controller's data table rather than being received as an electrical signal at one of the controller's physical inputs. To achieve this linkage between the controller's data table and the simulation, a middleware layer (e.g., an OPC server), is conventionally used to link the simulation's I/O points to the appropriate data table addresses within the controller. I/O data is then exchanged via the middleware layer, placing a non-deterministic layer between the simulation and the controller that can negatively impact transmission latency and data fidelity. This issue is often compounded by the fact that the plant simulation typically executes on a general-purpose computer or workstation, where the computer's operating system functions can interrupt simulation execution during validation.
Moreover, because the simulated I/O data is read from and written to the I/O data table directly by the middleware layer, the I/O modules and their associated module configurations are effectively bypassed during simulation. Consequently, simulated I/O data must be exchanged between the controller and the simulation as engineering units suitable for processing by the control program, rather than as raw values that would normally be received at the controller's I/O and scaled in accordance with the I/O module's user-defined scale factors. Since the I/O module configurations are not taken into consideration during validation, the simulation is rendered less representative of the real-world system. This also leaves the I/O module configurations themselves—as well as the control program's behavior given those module configurations—untested prior to deployment.
In a related problem, since the I/O module configurations cannot be used during execution of the simulation, it is necessary in some cases to disable or remove the I/O module configurations during simulation to allow the simulated I/O values to be written to the I/O data table registers. Another method for bypassing the I/O module configurations during simulation is to employ temporary controller addresses in the control program in lieu of the actual I/O addresses that will be used to send and receive I/O data when the system is deployed. Both of these techniques necessitate excessive configuration work, both to bypass the I/O module configurations prior to simulation, and to reinstate the module configurations when the system is deployed.
Also, middleware-based simulations, such as those using OPC server as described above, lack the ability to synchronize the respective clocks of the controller and the simulation. This lack of synchronization capability can adversely impact the fidelity of the simulation, since intensive processing on the simulation side can introduce unrealistic time delays in the exchange of I/O data.
The above-described deficiencies of today's automation control simulations systems are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.